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1 DETAILED ACTION 

2 

3 Continued Examination Under 37 CFR 1.114 

4 

5 A request for continued examination under 37 CFR 1.114, including the fee set 



6 forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this 

7 application is eligible for continued examination under 37 CFR 1.114, and the fee set 

8 forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action 

9 has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 9/27/06 
10 has been entered. 

11 

12 All objections and rejections not set forth below have been withdrawn. 

13 
14 

1 5 Specification 

16 

17 The specification is objected to as failing to provide proper antecedent basis for 

1 8 the claimed subject matter. See 37 CFR 1 .75(d)(1) and MPEP § 608.01 (o). Correction 

19 of the following is required: Claim 3 comprises the limitation "wherein the fragmenter 

20 module does not split the IKE data packets unless no response to a previously-sent IKE 

21 data packet has been received". The Applicant has not pointed out where the amended 

22 claim is supported, nor does there appear to be a written description of the claim 

23 limitation in the application as filed. 
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1 



2 Claim Rejections - 35 USC §112 

3 

4 The following is a quotation of the first paragraph of 35 U.S.C. 112: 

5 The specification shall contain a written description of the invention, and of the manner and process of 

6 making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the 

7 art to which it pertains, or with which it is most nearly connected, to make and use the same and shall 

8 set forth the best mode contemplated by the inventor of carrying out his invention. 
9 

10 Claim 3 is rejected under 35 U.S.C. 112, first paragraph, as failing to comply 



1 1 with the written description requirement. The claim contains subject matter 

12 which was not described in the specification in such a way as to reasonably 

13 convey to one skilled in the relevant art that the inventor(s), at the time the 

14 application was filed, had possession of the claimed invention. See above 

1 5 objection to the specification. 
16 



1 7 Claim Rejections - 35 USC § 103 

18 

1 9 The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 

20 obviousness rejections set forth in this Office action: 

21 (a) A patent may not be obtained though the invention is not identically disclosed or described as set 

22 forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 

23 the prior art are such that the subject matter as a whole would have been obvious at the time the 

24 invention was made to a person having ordinary skill in the art to which said subject matter pertains. 

25 Patentability shall not be negatived by the manner in which the invention was made. 

26 

27 Claims 1-3,6-8,10-18,20,22 and 23 are rejected under 35 U.S.C. 103(a) as 

28 being unpatentable over IPSEC, "Minutes of IPSEC Working Group Meeting", in 



29 view of Kent et al. (Kent), "Fragmentation Considered Harmful". 
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1 

. 2 Regarding claim 1, IPSEC discloses changes to the IKE protocol to support 

3 network transmission (i.e. NAT/Firewall traversal) (IPSEC, page 1 , #1 ) and the testing of 

4 the traversal of IKE packets over NAT devices, thus the generating and transmitting an 

5 IKE packet over a network (IPSEC, page 4, lines 1-7). IPSEC discloses that changes to 

6 the IKE protocol (to solve the IKE/NAT problem) are needed as packet fragmentation 

7 adversely affects IKE packets (IPSEC, page 4, par. 2; "Revised ESP", pars. 2, 3). 

8 IPSEC discloses as a solution that packets should be fragmented above UDP, resulting 

9 in multiple UDP packets - each packet encapsulating a fragment from the above and 

10 highest layer [application layer] where the IKE protocol stack operates (for evidence of 

1 1 protocol stacks, Applicant's representative may refer to the applicant's admitted Prior 

12 Art, fig. 4). Thus, IPSEC discloses fragmenting the IKE packet into a plurality of smaller 

13 packets and transmitting each of the plurality of smaller packets over a network (IPSEC, 

14 page 4, lines 1-7). 

15 IPSEC discloses that IKE packets should be fragmented before the UDP layer. 

16 However, IPSEC does not disclose specifically methods packet fragmentation, such as 

17 conditions requiring fragmentation and that a packet fragment should have a proper 

1 8 packet header. 

19 Kent et al. discloses principles for packet fragmentation. While Kent discusses 

20 these principals of packet fragmentation often in the context of the IP layer (Kent, pg. 

21 75, par. 4), Kent further discloses that these fragmentation methods are to be applied in 

22 higher protocol layers as well. Upper level protocol layers should be cognizant of 
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1 fragmentation issues, and should fragment or send smaller packet sizes if the it is 

2 known that a larger packet size will be fragmented at the IP layer (Kent et al., section 3, 

3 par. 4). For example, Kent discloses that an upper layer (i.e. TCP) should not send a 

4 large un-fragmented segment when it a lower layer (i.e. IP) will have to fragment it 

5 (Kent, pg. 79, pars. 3, 4). 

6 Kent discloses that the packet fragmentation method consists of fragmenting a 

7 larger packet into a plurality of fragments. Each fragment is sent as a separate packet, 

8 with each of the plurality of smaller packets containing a properly formatted header 

9 according to the protocol (Kent et al., section 2.1 ). 

1 0 It would have been obvious to one of ordinary skill in the art to employ the 

1 1 . principles for packet fragmentation disclosed by Kent with the teachings of IPSEC 

12 requiring the fragmentation of IKE packets above the UDP layer. This would have been 

13 obvious because one of ordinary skill in the art would have been motivated to practically 

14 implement packet fragmentation methods for the purpose of fragmenting IKE packets 

15 above the UDP layer as required by IPSEC, so that the packets would not be improperly 

16 fragmented at the IP layer. The combination of IPSEC and Kent discloses that 

17 fragmented packets each have a proper header, and thus, it would have been obvious 

18 to one of ordinary skill in the art to follow this teaching as required by the combination of 

19 IPSEC and Kent when fragmenting IKE messages before they are passed to the UDP 

20 layer. 

21 Therefore, the combination of IPSEC and Kent et al. discloses: 
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1 determining whether a response to the IKE packet was received and 

2 fragmenting the IKE packet into a plurality of smaller packets when a response is not 

3 received (Kent et al., section 3.3, pars. 1 - 3). To avoid improper fragmentation at the IP 

4 layer, the combination of IPSEC and Kent et al. discloses that a transmitting host would 

5 choose whether to fragment an IKE packet using received acknowledgements ("a 

6 response") of successful packet transmission. If the host does not receive an 

7 acknowledgment ("a response") then it will have to fragment it's transmitted packets into 

8 smaller packets until it receives a successful transmission acknowledgment, and 

9 accordingly discovers the proper fragment length for transmitting packets. 
10 



1 1 Regarding claim 2, the combination of IPSEC and Kent et al. discloses: 

1 2 wherein each header includes an identifier that may be used to associate the 

1 3 smaller packet with a corresponding IKE packet (Kent et al., section 2, par. 4, lines 1 -8; 

14 section 2.1, par. 2 ) 
15 

16 Regarding claim 3, it is rejected, at least, for the same reasons as claim 1 , and 

17 furthermore because the combination of IPSEC and Kent et al. discloses: 

1 8 a User Datagram Protocol (UDP) stack that is capable of generating UDP data 

19 packets for transmission over a network (IPSEC; page 4, lines 1-8). IPSEC discloses 

20 the generation of multiple UDP packets and the fragmentation of IKE packets above 

21 UDP (thus, a UDP stack) for network transmission; 
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1 an IKE protocol stack that generates IKE data packets that are subsequently 

2 processed by the UDP protocol stack (IPSEC; page 4, lines 1 -8). IPSEC discloses the 

3 generation and fragmentation of IKE packets (thus an IKE stack). The packets pass 

4 from a layer above UDP to a layer below UDP, and are fragmented above the UDP 

5 layer. 

6 and a fragmenter module that intercepts IKE data packets prior to being 

7 processed by to the UDP protocol stack and splits the IKE data packets into a plurality 

8 of smaller data packets that may be subsequently formatted by the UDP protocol stack 

9 (IPSEC, page 4, lines 1-8). IPSEC discloses fragmenting IKE packets (thus a 

10 fragmenter module) in a layer above the UDP layer (thus intercepting IKE packets prior 

1 1 to being processed by the UDP stack). 



1 2 wherein the fragmenter module does not split the IKE data packets unless no 

1 3 response to a previously-sent IKE data packet has been received (Kent et al., section 

14 3.3, pars. 1 - 3). Herein, the combination discloses that once a suitable response is 

15 received, the fragmenter module does not continue to split the data packets. 

1 6 and wherein, each of the plurality of smaller data packets includes a header 

1 7 formatted according to the IKE protocol (see rejection of claim 1 ). 
18 

19 Regarding claim 6, the combination of IPSEC and Kent et al. disclose: 

20 receiving a plurality of fragments of an IKE data packet from a transmitting node, 

21 wherein each fragment includes an identifier that associates each fragment with an IKE 
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1 data packet ; and discarding all fragments that contain a first identifier if a 

2 predetermined number of fragments are received that contain a second identifier ( Kent 

3 et al., section 2.4, par. 3); 

4 and determining the total size of all fragments that contain the same identifier 

5 and discarding said fragements when the total size exceeds a predetermined limit (Kent 

6 et al., section 2.4, par. 2, 3). Herein, the combination discloses that a fragment 

7 reassembly process may not progress if the total size of a datagram (comprising 

8 fragments with a same identifier) exceeds a predetermined limit. As an example, a 

9 sufficiently sized space for reassembling a large datagram could comprise a size of 8 

1 0 buffer spaces. Thus, when that predetermined limit is achieved, the occupying 

1 1 fragments of an unassembled datagram will expire and be discarded. 
12 



13 Regarding claim 7, the combination of IPSEC and Kent et al. disclose: 

1 4 wherein the step of discarding all fragments that contain a first identifier is 

1 5 performed when at least one fragment is received that contains a second identifier (Kent 

16 et al., section 2.4, par. 3). 
17 

18 Regarding claim 8, the combination of IPSEC and Kent et al. disclose: 

1 9 determining whether all fragments that are associated with an IKE data packet 

20 have been received, and sending a no acknowledgment (NAK) message to the 

21 transmitting node when at least one fragment has not been received (Kent et al., section 

22 3.3.3). A receiving host is disclosed as making a determination as to whether all 
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1 fragments associated with an IKE packet has been received. The receiving host will 

2 convey a "Time exceeded" message ("NAK") to the transmitting host when at least one 

3 fragment has not arrived, indicating to the transmitting host that it has not received all 

4 the fragments. 
5 

6 Regarding claim 10, the combination of IPSEC and Kent et al. does not disclose 

7 wherein the predetermined limit is 64 kilobytes. This, however, would have been 

8 obvious to one of ordinary skill in the art to set a predetermined limit of 64 kilobytes as 

9 the total size of all possible fragments. As evidenced by the "Glossary for the Linux 

10 FreeS/WAN project" - (definition for DoS), this would have been obvious to one of 

1 1 ordinary skill in the art because the standardized size limit of an IP packet is 64 

12 kilobytes, and a failure to discard illegitimate packets when the size exceeds the 

1 3 standard limit would result in denial of service attacks. 
14 

15 Regarding claim 1 1 , it is rejected, at least, for the same reasons provided for the 

16 rejection of claims 1 and 2, and furthermore because the combination discloses that to 

17 avoid unnecessary fragmentation of packets (Kent, section 3.2), the system should be 

1 8 cognizant of network timing issues. Thus, a system will not assume it is necessary to 

1 9 retransmit a packet until a determined period of time ("round-trip time" or the estimated 

20 time period between a, sender's packet transmission and a sender's reception of a 

21 packet acknowledgement response)(Kent, section 3.2. 1 ). 
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1 While the combination does not nominally recite "a timer", it would have been 

2 obvious to one of ordinary skill in the art to employ appropriate timing means ("a timer") 

3 for determining when packet retransmission is necessary. This would have been 

4 obvious because one of ordinary skill in art would have been motivated by the 

5 combination's teachings for measuring and determining timing delays before 

6 retransmitting previously transmitted packets within a system. 
7 



8 Regarding claim 12, the combination of IPSEC and Kent et al. disclose: 

9 further comprising means for determining the capability of the receiver node for 
10 receiving fragmented packets (Kent et al., section 3.3, par. 2). 

11 

12 Regarding claims 13, 14, and 15 they are rejected, at least, for the same reasons 

13 as claims 1 and 2. 
14 

15 Regarding claim 16, the combination of IPSEC and Kent et al. disclose: 

1 6 wherein the plurality of smaller packets contain the same information as that 

1 7 contained within the original IKE packet (Kent et al., section 2.4, par. 3, section 2.1 ). 
18 

19 Regarding claim 17, the combination of IPSEC and Kent et al. disclose: 

20 wherein at least one of the plurality of smaller packets contains the header 

21 formatted according to the IKE protocol (Kent et al., section 2.1). As disclosed by the 

22 combination of IPSEC and Kent et al., fragmentation involves fragmenting the original 
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1 packet into smaller packets, each containing the protocol and header fields of the 

2 original packet. 
3 

4 Regarding claim 18, it is rejected, at least, for the same reasons as claims 1 and 

5 11, and furthermore because the combination of IPSEC and Kent discloses: 

6 wherein the steps of generating, determining and fragmenting are performed 

7 independently of performing any steps on the data packet corresponding to a transport 

8 layer protocol and/or a network layer protocol (IPSEC, page 4, lines 6-8). The 

9 combination of IPSEC and Kent discloses generating and fragmentation (accordingly 
1 0 determination to fragment) as occurring before the lower protocol layers. 

11 

12 Regarding claim 20, it is rejected, at least, for the same reasons as claims 1 and 

13 11, and further because the combination of IPSEC and Kent et al. disclose: 

1 4 fragmenting the packet into a plurality of fragments using a code module that 

1 5 does not implement the TCP, UDP or IP protocols before the packet is processed by a 

1 6 code module that does implement the TCP, UDP or IP protocols (IPSEC; page 4, lines 

17 1-8; Kent et al., section 3). The combination of IPSEC and Kent et al. disclose the 

1 8 fragmentation of IKE packets above the UDP layer - this would include TCP (parallel to 

19 UDP) and IP (below UDP). The fragmentation is computer based and therefore 

20 inherently performed by some type of module for instructing a computer ("code 

21 module"). 
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1 comprising including an identifier that identifies the data packet in eah packet 

2 fragment (see rejection of claim 2); and transmitting the packet fragments over a 

3 network (see rejection of claim 1 ). 
4 

5 



6 Claims 22 - 23 are rejected under 35 U.S.C. 103(a) as being unpatentable 

7 over the combination of IPSEC and Kent in view of Cerf et al. (Cerf), "A Protocol 

8 for Packet Network Intercommunication". 

9 

10 Regarding claim 22, the combination of IPSEC and Kent et al. disclose: 

1 1 receiving a plurality of fragments of a single IKE data packet, wherein the 



1 2 fragments were transmitted from a transmitting node in an order that can be determined 

1 3 from information contained within the received data fragments (Kent et al.; section 2.1, 

14 par. 3; section 2.4, par. 3). The combination does not disclose that a receiver may 

1 5 detect duplicate packets from a single IKE packet and then discard such duplicates. 

16 Cerf discloses that a receiver which receives duplicate packets will discard such 

1 7 duplicates. Additionally, Cerf discloses that a receiver may detect out of order packets, 

18 and choose to store and acknowledge such packets or discard such packets (Cerf, pg. 

19 7-8, "Retransmission and Duplicate Detection"). It would have been obvious to one of 

20 ordinary skill in the art to detect and discard duplicate packets. This would have been 

21 obvious because one of ordinary skill in the art would have been motivated to avoid 

22 resource consummation by superfluous data. 
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1 

2 Regarding claim 23, the combination discloses sending a message to the 

3 transmitting node that out of order packets have been received (Cerf, pg. 7-8, 

4 "Retransmission and Duplicate Detection"). 
5 

6 Response to Arguments 

7 

8 Applicant's arguments filed 9/25/06 have been fully considered but they are not 

9 persuasive. 
10 

1 1 Applicant's representative argues primarily that: 

12 

1 3 (i) Neither IPSEC nor Kent, nor their combination, teaches or suggests using the 

1 4 absence of a response to an IKE packet to determine whether to fragment IKE packets. 

15 (Remarks, pg. 8) 
16 

1 7 In response, the examiner finds the arguments of the applicant's representative 

18 to be unpersuasive. The prior art combination does in fact disclose that a transmitter 

19 will continue to fragment a transmitted datagram until a response is received from a 

20 receiver informing the transmitter that the data has been properly received (applicant 

21 are respectfully encouraged to review the prior art references and the rejection of claim 

22 1). 
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1 

2 (ii) Kent does not teach or suggest determining the total size of all fragments that 

3 contain the same identifier, nor does it teach or suggest discarding said fragments when 

4 the total size exceeds a predetermined limit. IPSEC does not remedy this deficiency in 

5 Kent. (Remarks, pg. 9) 
6 

7 In response, the examiner finds the arguments of the applicant's representative 

8 to be unpersuasive. The prior art combination does in fact disclose determining a total 

9 size of assembled fragments and the discarding of fragments when a total size exceeds 

10 a predetermined limit (unassembled fragments whose total size exceeds the limit will 

1 1 expire and be discarded). The examiner respectfully encourages the applicant to 

1 2 review the prior art references and the rejection of claim 6. 
13 

1 4 The examiner notes that other arguments by the applicant are essentially similar 

15 to the ones above and are new arguments directed towards new/amended limitations. 
16 

17 

1 8 Conclusion 

19 

20 The prior art made of record and not relied upon is considered pertinent to 

21 applicant's disclosure. 
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1 See Notice of References Cited 

2 

3 A shortened statutory period for reply to this final action is set to expire THREE 

4 MONTHS from the mailing date of this action. In the event a first reply is filed within 

5 TWO MONTHS of the mailing date of this final action and the advisory action is not 

6 mailed until after the end of the THREE-MONTH shortened statutory period, then the 

7 shortened statutory period will expire on the date the advisory action is mailed, and any 

8 extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 

9 the advisory action. In no event, however, will the statutory period for reply expire later 

1 0 than SIX MONTHS from the date of this final action. 

1 1 Any inquiry concerning this communication or earlier communications from the 

1 2 examiner should be directed to Jeffery Williams whose telephone number is (571 ) 272- 

13 7965. The examiner can normally be reached on 8:30-5:00. 

14 If attempts to reach the examiner by telephone are unsuccessful, the examiner's 

15 supervisor, Emmanuel Moise can be reached on (571) 272-3865. The fax phone 

16 number for the organization where this application or proceeding is assigned is 571- 

17 273-8300. 
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Information regarding the status of an application may be obtained from the 



2 Patent Application Information Retrieval (PAIR) system. Status information for 

3 published applications may be obtained from either Private PAIR or Public PAIR. 

4 Status information for unpublished applications is available through Private PAIR only. 

5 For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 

6 you have questions on access to the Private PAIR system, contact the Electronic 

7 Business Center (EBC) at 866-21 7-91 97 (toll-free). If you would like assistance from a 

8 USPTO Customer Service Representative or access to the automated information 

9 system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 



10 



11 
12 
13 
14 
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